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Request to Move RFC 2754 to Historic Status 

Abstract 
RFC 2754 requested that each time IANA made an address assignment, it 
was to create appropriate inetnum and as-block objects and digitally 
sign them. The purpose was to distribute the IANA-held public key in 
software implementations of the Distributed Routing Policy System. 
In practice, this was never done on the public Internet. This 
document requests that RFC 2754 be moved to Historic status. 


Status of This Memo 


This document is not an Internet Standards Track specification; it is 
published for informational purposes. 


This document is a product of the Internet Engineering Task Force 


(IETF). It represents the consensus of the IETF community. It has 
received public review and has been approved for publication by the 
Internet Engineering Steering Group (IESG). Not all documents 


approved by the IESG are a candidate for any level of Internet 
Standard; see Section 2 of RFC 5741. 


Information about the current status of this document, any errata, 
and how to provide feedback on it may be obtained at 
http://www.rfc-editor.org/info/rfc6254. 


Copyright Notice 


Copyright (c) 2011 IETF Trust and the persons identified as the 
document authors. All rights reserved. 


This document is subject to BCP 78 and the IETF Trust’s Legal 
Provisions Relating to IETF Documents 
(http://trustee.ietf.org/license-info) in effect on the date of 
publication of this document. Please review these documents 
carefully, as they describe your rights and restrictions with respect 
to this document. Code Components extracted from this document must 
include Simplified BSD License text as described in Section 4.e of 
the Trust Legal Provisions and are provided without warranty as 
described in the Simplified BSD License. 
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1. Introduction 


The Internet Assigned Numbers Authority (IANA) (www.iana.org) is 
charged with allocating parameter values for fields in protocols that 
have been designed, created, or are maintained by the Internet 
Engineering Task Force (IETF). RFC 2754 [RFC2754] requests that the 
IANA create a repository of Routing Policy Specification Language 
(RPSL) objects and digitally sign them. The RFC identifies the 
initial objects to be signed and also requests that each time IANA 
makes an address assignment it also create new objects as needed and 
sign them as well. In practice, this was never done in the public 
Internet. During a detailed review of IANA’s protocol registration 
activities in support of the IETF, this request for IANA action was 
identified as one of those that had not been completed after 
publication of the RFC. 


This document obsoletes RFC 2754 [RFC2754], recommends that it be 
moved to Historic status, and directs IANA not to move forward with 
the IANA actions in that RFC. 


2. Details 


RFC 2754 [RFC2754] requests that the IANA create a repository of RPSL 
objects and digitally sign them. The RFC identifies the initial 
objects to be signed and also requests that each time IANA makes an 
address assignment it also create new objects as needed and sign them 
as well. 


During a review of RFCs in 2009, it became apparent that the IANA 
actions requested in RFC 2754 were never done. In the intervening 
time, another technology appears to be taking the role once 
envisioned for Distributed RPSL. Both an architecture and 
infrastructure now exist for secure routing using Resource Public Key 
Infrastructure (RPKI) technologies. As an example, the semantics of 


a Route Origin Authorization (ROA) -- an application of the RPKI -- 
to validate the origination of routes has been standardized by 
the IETF. 
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Implementation of the IANA actions in RFC 2754 would now require 
significant implementation complexity. In the face of alternative 
technology, and given that the requested actions have not been 
implemented in the public Internet, it is proposed to reclassify 
RFC 2754 [RFC2754] as Historic and to direct the IANA not to pursue 
or implement the IANA requests in that document. 


3. Terminology 


The word "allocation" designates a block of addresses managed by a 
registry for the purpose of making assignments and allocations. The 
word "assignment" designates a block of addresses, or a single 
address, registered to an end-user for use on a specific network, or 
set of networks. 


4. IANA Considerations 


IANA is instructed not to pursue or implement the IANA actions 
requested in RFC 2754 [RFC2754]. 


5. Security Considerations 


The intended signature of inetnum and as-block objects never took 
place in the public Internet. Moving RFC 2754 [RFC2754] to Historic 
status would have no known impact on the security of the Internet. 
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